Online verification of an individual comprises two parts: establishing the existence of an identity that is allowed to perform the transaction, and establishing that the present user has that identity. A common method for establishing the existence and content of the online identity claimed by the user is to ask the user for personal information items that are presumed to be known by him and by the system but by no one else. These items fall into two broad (and somewhat overlapping) categories: what we call herein “in-wallet” and “out-of-wallet” data.
In-wallet data is data you know about yourself or can find quickly and easily, for example by consulting cards carried “in your wallet”. Name, address, telephone number, Social Security number (SSN), driver's license number (DLN), and birth date are examples of in-wallet data. Mortgage holder, last transaction amount to a merchant or government agency, and car registration number are examples of out-of-wallet data. Often in- and out-of-wallet data are used sequentially to authenticate a person. In-wallet data is used to determine which identity is claimed, and then out-of-wallet data (presumably harder for a fraudster to obtain) is used to establish that the user is that person.
The difficulty with this approach is that for it to work, the “private” data of the user (e.g. out-of-wallet data) must be revealed to the authenticator so the authenticator can compare it with its file of authenticating information. This has two problems. First, the user must give the authenticator his private data and second, the authenticator had to get that data from some other source who gathered the data in the first place. Thus, as currently constructed, such a system only works if the authenticator already has a compendium of “private” data against which to compare the user's information.
Almost always that data comes from a third party who gathered the data. There are therefore at least three parties who have the “private” data—the user, the authenticator, and the third party provider. Worse yet, much of the so-called “private” data was gathered by the third party from “public” sources—phone books, credit reports, and the like. If the third party isn't the entity that gathers the data directly from the user, then they are in the same situation as the authenticator—they have to get the data from yet another party. There is no telling how many hands the “private” data passes through prior to its being used for authentication.
This presents a contradiction: to be useful for authentication, the user's data must be “private” (otherwise spoofers can get at it), but it also must be available to the authenticator—which reduces its privacy. Given the large number of authenticators currently working, and the small number of available data items on a person, it becomes clear that the more a data item is used for authentication, the less reliable it is for authentication. The increasing reluctance of users to supply social security number or mother's maiden name (two of the most common data elements previously used for authentication) indicates that users have a (correct) feeling that each use of such information makes it less private, and hence increasingly exposes the user to identity theft. Users, therefore, are increasingly reluctant to put private information in the hands of authenticators, no matter how trustworthy they believe the authenticators to be.
We have observed, however, that there are certain entities that users routinely trust with their private information: those whose business it is to use the information for its original purpose. For example, no one thinks twice about his bank possessing his bank account numbers or knowing the balance in his checking account. Banks are supposed to have that information, and require it to perform the functions users expect of them. Utilities are assumed to hold user utility bill information, such as gas and electric bills. Wireless telecommunications carriers hold a mountain of cell phone user call data.